COMMENT ⊗   VALID 00004 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	AL/ARM ethernet packet communication protocol
C00009 00003	ARM message record 
C00010 00004	AL message record (on SAIL)
C00012 ENDMK
C⊗;
AL/ARM ethernet packet communication protocol

HELLOP ← 200		;Pup types for AL-ARM communication (octal values)
ARMFRE ← 201
ARMBSY ← 202
THEREP ← 203
ALLIVE ← 204
ALARM  ← 205
ACK    ← 206
BYEBYE ← 207

Socket for ARM server = 106
Socket for Talk server = 105

Pup packets for AL come in two sizes: 22+76=98 bytes for ALARM messages and
minimal 22 byte packets for everything else.

Before anything can be done a connection between AL on the 10 & an ARM servo
on either the 11/45 or 11/60 must be established.  To do this AL will send a
HELLO packet to the 11/45 (Ubehebe = host 304), directed to socket 106.  The
ARM server should reply by sending an ARMFRE pup back.  If the ARM servo is
currently in use it should send an ARMBSY pup back.  If nothing is sent back
to AL it will time out and resend the HELLO packet in two seconds.  A total of
five HELLO packets will be sent (giving the ARM code 10 seconds to reply)
before AL gives up. (If an ARMBSY pup is received AL immediately gives up.)
If the 11/45 doesn't establish the connection, AL will then repeat the above
process with the 11/60 (Pisgah = host 323).  After establishing a connection
AL reports to which 11 it is talking.  If neither machine answers then AL
reports a failure to connect with the ARM servo and enters simulation mode.
Issuing a CALIBRATE command will attempt to establish a connection at a later
time, if one does not exist.

If the ARM servo wishes to check that AL is still alive, as it might when
receiving a HELLO pup from another AL job, it can do so by sending a THEREP
pup to AL.  If AL is indeed still there it will reply with an ALLIVE pup.
If there is no reply to a THEREP pup the ARM servo can flush it's old connection
and establish a new connection with the AL sending the HELLO pup.  As noted
above there is a window of approximately 10 seconds between the arrival of a
HELLO pup & when AL will give up on making the new connection, so the ARM servo
has a chance to decide if it really is busy or not.

When AL is exited it will send the ARM servo a BYEBYE pup.  Currently there is
no handshaking --- after sending the BYEBYE pup AL does not wait for any
acknowledgement from ARM before disappearing.

Once a connection is opened then any data is sent from AL to/from ARM via
ALARM pups, which contain 38 16-bit words.  Upon receiving an ALARM pup an
ACK pup must be sent back to the sender of the ALARM packet.  If no ACK is
received then after a suitable period (currently one second for AL) the sender
should time out and retransmit the original ALARM pup again.  The ALARM pup
must be acknowledged via an ACK before any other ALARM pup can be sent.  I.e.
a new message can't be sent until the old one has been successfully received.
AL will try up to five times to send out an ALARM pup before it gives up and
reports that the ARM isn't responding.

To insure that an ACK pup is really acknowledging a specific ALARM message,
each ALARM pup is assigned a unique number by its sender.  This number is sent
in the PUP ID field of the packet.  The corresponding ACK packet will have the
same number in its PUP ID field.  This sequence number should be monotonically
increasing so each receiver can detect duplicate ALARM packets, which can be
discarded, though another ACK must be sent. (The original ACK was probably
lost.)  Note that there are two independent sequences going on:  one for ALARM
packets being sent from AL to ARM, and another for those being sent from ARM
to AL.  When the connection is initially established both AL and ARM should
initialize their own sequence numbers to some suitable value (AL uses zero)
and thereafter increment their own sequence number by one before sending out
an ALARM message.  Both AL and ARM should also keep track of the other's
current sequence number, so if an ALARM message is received with its PUP ID
field set to less than the expected incoming sequence number it can be
recognized as a duplicate pup packet and discarded.

ARM message record 

message = RECORD
	   next: messagep;			{word}
	   cmd: msgtypes;			{byte}
	   ok: boolean;				{byte}
	   dev, bits, n, evt1,evt2: integer;	{word}
           dur: real;				{double word}
	   CASE integer OF
           1: (v: vect;				{double word}
              CASE integer OF
	      1: (t: trans);
	      2: (v6: vect6);
	      3: (fv1,fv2,fv3,mv1,mv2,mv3: real));
	   2: (sfac,wobble,pos: real);
           3: (val,angle,mag: real);
           4: (max,min: real);			{double word}
           5: (error: errortypes);		{byte}
	  END;

AL message record (on SAIL)

(* definition of AL-ARM messages *)

msgtypes = (initarmscmd,calibcmd,killarmscmd,wherecmd,
	    abortcmd,stopcmd,movehdrcmd,movesegcmd,
	    centercmd,operatecmd,movedonecmd,signalcmd,
	    setccmd,forcesigcmd,forceoffcmd,biasoncmd,biasoffcmd,setstiffcmd,
	    zerowristcmd,wristcmd,gathercmd,getgathercmd,readadccmd,writedaccmd,
	    errorcmd,floatcmd,setloadcmd,
	    armmagiccmd,realcmd,vectorcmd,transcmd);

errortypes = (noerror,noarmsol,timerr,durerr,toolong,featna,
	      unkmess,srvdead,adcdead,nozind,exjtfc,paslim,nopower,badpot,devbusy,
	      baddev,timout,panicb,nocart,cbound,badparm);

message = record
	   ok: boolean;
	   cmd: msgtypes;
	   dev: integer;
	   bits: integer;
	   n: integer;	
	   error: errortypes;			(* for AL *)
(*	   dev, bits, n, evt1, evt2: integer;	(* for (16-bit) ARM code *)
	   evt: eventp;
           dur: real;
	   case integer of
	   1: (v1: real;
		v2: real;
		v3: real;
		t: array [1..12] of real);
	   2: (sfac: real;
		wobble: real;
		pos: real);
           3: (val: real;
		angle: real;
		mag: real);
(*         4: (error: errortypes);	field here in ARM code version *)
	  end;